Phase 1a.4: delete the --rr-* alias block (zero visual delta) - #527
Merged
Conversation
The deletion Phase 1a.4 owns. Its precondition was that all three consumers stop using the alias names, and the rule is to re-grep at deletion time rather than trust a written inventory - which mattered, because an earlier inventory of these consumers was wrong twice in one review. Measured before: `grep -rn 'var(--rr-' themes/beaver/assets/css/` returned 18 across pages/blog-list.css (9), single-post.css (6) and pages/blog-single.css (3). Migrated each to its canonical name, then re-grepped: 0. Only then deleted the alias block from foundations/css-variables.css. Zero visual delta is guaranteed by construction, not hoped for: every alias was defined as `var(--rr-X: var(--X))`, an exact 1:1 indirection, so removing the hop cannot change a computed value. The suite agrees - 53 screenshots compared, no failures, no baseline moved. This also removes the trap recorded in design/site-palette.md: the aliases were consumed by single-post.css, which belongs to the COURSE bundle as well as the blog, so deleting the block while any consumer remained would have broken styling on both. That risk is now gone rather than documented. Gate: bin/test - 34 runs, 87 assertions, 0 failures, [snap_diff] 53 screenshots compared, no failures. bin/hugo-build clean. macOS only; Linux baselines belong to the parallel PR and were not touched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
design/site-palette.md updated from "the --rr-* aliases die next in 1a.4" to gone: 18 references migrated, block removed, zero visual delta by construction. Kept the part that outlives the deletion - verify a precondition by RUNNING the check, never by reading what the check returned last time. A written inventory of those exact consumers was wrong twice in one review (omitted a live line, named a file with zero references), and single-post.css belongs to the COURSE bundle as well as the blog, so deleting on the doc's word would have broken both. Re-grepping at the moment of deletion turned that from a risk into a non-event: 18 -> 0 -> delete. Log also records the re-scope: "footer onto surface-ink" is not a footer change, and its remaining half needs dividers and adjacent dark sections migrated together across 7+ bundles. Timestamp anchored to a measured `date -u` (2026-08-21T02:05:49Z). Gates: okf_validate .okf exits 0 conformant; --strict exits 1 as it does on this bundle by design. bin/hugo-build clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The deletion Phase 1a.4 owns. Zero visual delta, and that is guaranteed by
construction rather than hoped for.
What landed
All 18
--rr-*references migrated to canonical names, then the alias blockremoved from
foundations/css-variables.css:pages/blog-list.csssingle-post.csspages/blog-single.cssEach alias was
--rr-X: var(--X)— an exact 1:1 indirection — so removing thehop cannot change a computed value.
The precondition was re-run, not read
The rule is to re-grep at the moment of deletion rather than trust a written
inventory. That mattered here: an inventory of these same consumers was wrong
twice in one review — it omitted a live line and named a file carrying zero
references.
single-post.cssbelongs to the course bundle as well as the blog, sodeleting on the strength of that inventory would have broken styling on both.
Re-running the check turned a real risk into a non-event.
Gates
bin/test— 34 runs, 87 assertions, 0 failures,[snap_diff] 53 screenshots compared, no failures. No baseline moved, as predicted.bin/hugo-buildcleanokf_validate .okfexits 0, conformant;--strictexits 1, as it doeson this bundle by design — reported, not called green
Scope note
1a.4's other half — "footer onto
surface-ink" — is blocked and re-scoped;see #526. It is not a footer change: moving it leaves adjacent dark surfaces at
pure black, and fixing those requires migrating dividers and the dark sections
they abut together across 7+ page bundles.
🤖 Generated with Claude Code